Skip to content

Fix editData in HTML/UWP extensions allocating too much data#31

Merged
SortaCore merged 2 commits into
SortaCore:masterfrom
AITYunivers:data-alloc-size-fix
Jun 13, 2026
Merged

Fix editData in HTML/UWP extensions allocating too much data#31
SortaCore merged 2 commits into
SortaCore:masterfrom
AITYunivers:data-alloc-size-fix

Conversation

@AITYunivers

Copy link
Copy Markdown
Contributor

editData is allocated using
(in v1)

this.sizeBytes - header.byteLength

(in v2)

this.sizeBytes -
// skip area between eHeader -> Props
(ext.ho.privateData - 20) -
// Skip DarkEdif header
header.byteLength

neither of these equations account for the size of eHeader, and in v2 the header not including verStr in it's length.

This PR fixes these by subtracting eHeader and by subtracting 4 (in the Template only as the extensions are v1)

AITYunivers and others added 2 commits April 29, 2026 21:44
Offset calculation was incorrect. Thanks to @AITYunivers for initial spotting.

privateData stores the offset from EDITDATA start to Props start. It should skip both eHeader and any in-between variables.
eHeader is 20 bytes; that's a fixed C struct, always at start of any SDK EDITDATA. However, it's not passed in with edPtrFile, as the runtime itself reads the eHeader and pushes past it.
Props is DarkEdif only, varying size, and always at end of EDITDATA.

DarkScript prop edits are kept, but note it's not even updated to SDK v20, or v2 prop sets yet.

Bluewing prop edits kept, although Bluewing doesn't use DarkEdif smart props, doing everything manually instead. Properties there are only kept because it means no extra edits for the DarkEdif starter code.
@SortaCore SortaCore merged commit c23cf35 into SortaCore:master Jun 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants